This invention relates generally to computer graphics. More particularly, this invention relates to method and apparatus for enabling an application program to efficiently draw bitmapped images in a standard format that is independent of the device on which the images are created or displayed. Bitmaps of this format are known as device-independent bitmaps, or DIBS. The invention also relates to method and apparatus for simplifying the design of graphics drivers such as display drivers for displaying such bitmaps.
In the field of computer graphics, there are two common ways of storing pictorial information: bitmaps and metafiles. A metafile stores an image as a series of instructions that draw the image, such as instructions to draw a circle, add text, etc. A bitmap, on the other hand, is a complete digital representation of an image. Each pixel in the image corresponds to one or more bits in the bitmap. Monochrome bitmaps require only one bit per pixel; color bitmaps require additional bits to indicate the color of each pixel. Bitmaps can exist in a computer""s memory or can be stored on a disk or other storage device as files.
Bitmaps have the advantage over metafiles in the time required to generate an image. Copying a bitmap from memory or storage to a video display is much faster than rendering an image using a metafile. However, bitmaps have a number of drawbacks. They are in many respects device dependent, such as for color and spatial resolutions. For example, displaying a color bitmap on a monochrome display device is often unsatisfactory. And where the spatial resolution of the bitmap (i.e., number of pixels in each row and column of the bitmap) differs from the display device, the displayed bitmap is often distorted.
Recognizing the value of bitmaps and their drawbacks, computer operating systems have been designed to support device-independent bitmaps, or DIBS. Because their format is independent of a particular display device""s requirements, DIBs have the advantage over other bitmaps (often referred to as device-dependent bitmaps) in that they may easily be used by other application programs and may be displayed on other display devices. The DIB format is well documented in the literature, such as in Programming Windows 3.1, available from Microsoft Press. Briefly, a DIB file typically includes a structure with a number of information fields that specify the width and height of the bitmap in pixels, the color bits per pixel and other pertinent information. These fields are followed by a color table if the DIB has 8 or fewer bits per pixel. For bitmaps of a certain number of bits per pixel, the table includes entries that specify the intensity of the red, green and blue color for a pixel. A DIB file concludes with an array of bits that define the particular bitmap image, with a number of bits representing each pixel of the image. The bits representing a particular pixel serve as an index into the color table, thereby specifying the color for the pixel.
However, the present process for enabling an application program to use the DIB format is inefficient. Typically, an application program can presently draw onto a DIB in one of two ways. In the first way, the application program includes special code that allows it to create a DIB in memory and then draw onto a DIB. This approach, while taking full advantage of the application program""s drawing capability, has drawbacks. It requires that the code perform all of the graphics routines, even such simple routines as drawing a line or rectangle. These routines are expensive to write and duplicate many of the drawing routines offered by the operating system. In the second way, the application program uses the capability of the computer""s operating system for working with DIBS. This second approach is simpler from the viewpoint of the application program, but is more time consuming and more limited in capability than the first approach. With respect to time, the application program must make several calls to the operating system. For example, to draw onto a DIB using the Windows operating environment from Microsoft Corp. of Redmond, Wash., the application program calls a function within Windows to draw onto a device-dependent bitmap, or DDB. The application then calls another function to transfer the DDB into the DIB. With respect to drawing capability, operating systems such as Windows typically have only a few functions for drawing figures. To draw more fanciful figures, the application program must use the first approach.
The first approach may combined with the second approach to minimize the complexity of the application program. The application program then handles drawing of the more difficult shapes and the operating system handles drawing of the simpler shapes such as rectangles, circles, etc. But this combined approach requires even more function calls between the application program and the operating system.
Related to the use of the operating system to draw onto a bitmap is the role of graphics drivers such as display drivers or printer drivers. A graphics driver is a module of code that operates a graphics device such as a display device or printer and includes within it a collection of graphics functions designed to work with a particular graphics device. The operating system calls these graphics functions to interact with a particular graphics device. Typically each graphics device has its own graphics driver, which is written to take advantage of the particular capabilities of the graphics device. When an operating system receives a function call from an application program to perform a drawing operation, the system makes a similar call to a graphics driver. The graphics driver then carries out the graphics operation on the graphics device.
A drawback of present graphics drivers is their duplication of code. For example, typically there are display drivers for a number of common display devices such as EGA and VGA displays resident in memory at the same time. Each of these drivers contains similar graphics functions, resulting in a substantial duplication of code resident in memory.
Another drawback of graphics drivers is their complexity. Many display devices have special characteristics that require display drivers to be written to take advantage of these characteristics. A true color (24-bit) display card, for example, may require a display driver that is not supplied with the operating system software. The supplier of the card must then provide the required display driver. To do so, the supplier must have intimate knowledge of the operating system that interacts with the display driver. Gaining that knowledge and writing the appropriate code is a time consuming and expensive process.
The objects of the invention are therefore several. One object is to provide an operating system that allows an application program to draw onto device-independent bitmaps in an efficient manner. The application program should not require special code to perform the drawing. If the application program desires to use the drawing capabilities of the operating system to draw onto a DIB, the steps required for doing so should be minimized. A second object is to provide an operating system that can support drawing by the application program onto other bitmaps and output devices without the need for complex and redundant code in the graphics drivers. For example, each display driver should contain only code that takes advantage of its display device""s unique characteristics. Redundant code for drawing functions that are common to all display drivers should be removed, and those functions left to the operating system. This change in display driver responsibility reduces the amount of code required to be resident in main memory. This change also simplifies the writing of such graphics drivers.
A method and apparatus in accordance with the invention is disclosed for enabling an application program to use the operating system to create a device-independent bitmap on which the application may then perform graphics operations. The method includes accessing a data structure describing a desired format for the bitmap. A bitmap is then created according to the desired format. The bitmap is identified to both the operating system and to the application program, enabling the application program to perform graphics operations on the bitmap directly or through the facilities of the operating system.
In one embodiment of the invention, the operating system includes a graphics interface and a graphics engine. The application program calls a first function in the graphics interface to create the DIB. The graphics interface, in turn, calls a second function in the graphics engine to create the DIB. The graphics engine returns to the graphics interface a means for identifying the bitmap to the application program, such as a pointer to the DIB""s memory location. The graphics interface then returns to the application program a means for identifying the bitmap to the operating system and the means for identifying the bitmap to the application program.
In another aspect of the invention, the graphics engine carries out drawing operations that previously have been incorporated into graphics drivers. This reduces the tasks of graphics drivers, allowing their code to be limited to handling any special characteristics of the graphics hardware associated with the graphics driver. In the method of the invention, a function call is made to the graphics driver to perform a graphics operation. The graphics driver then determines whether the graphics operation is of a type that the graphics engine may perform. If it is, the graphics driver calls a function in the graphics engine to perform the operation. If it is not, the graphics driver performs the operation.